Adding support for storm control on L2 interfaces and copy description on PC - #855

@juarocha - Please check if this scenario would be an issue:

Rule 312 iterates switch.get('interfaces') but VPC peer configurations live under vxlan.topology.switches[].vpc_peers[].interfaces (or similar path).

The VPC template now renders storm control for VPC interfaces. If a user sets both _percent and _pps on a VPC peer interface, Rule 312 would not catch it.

Confirm whether VPC peer data is in a different path that needs a second traversal.

Approved.

1. Consistent implementation across all 5+ interface templates — storm control blocks are identical in ndfc_interface_access.j2, ndfc_interface_access_po.j2, ndfc_interface_dot1q.j2, ndfc_interface_trunk.j2, ndfc_interface_trunk_po.j2, and ndfc_interface_vpc.j2.
2. Defaults properly seeded — defaults.yml updated for all affected interface types (dot1q, access, trunk, access_po, trunk_po). New copy_description: false default added wherever copy_description was introduced.
3. Validation rule 312 added — New 312_topology_interface_storm_control.py enforces the mutual exclusivity of percent vs. PPS. Good defensive validation.
4. vPC rule 305 bug fix is a real fix — The old logic (len(interfaces["interfaces"]) == 2) was incorrect in multi-fabric scenarios. The new per-pair iteration logic correctly scopes the consistency check to actual vPC peers.
5. data_model_key_check is self-contained — Rule 312 copies the utility method locally rather than inheriting from a base class inconsistently, matching the pattern of other rules in the codebase.
6. All CI passes — Clean across all Python/Ansible matrix combinations.

Rule 312 assumes storm control is disabled whenever enable_storm_control is not explicitly repeated on the interface, but, this setting can also be inherited from defaults.vxlan

Since semantic validation runs before factory and custom defaults are merged, a valid interface that inherits enable_storm_control: true and only defines
its threshold is rejected.

Could Rule 312 validate the effective value using this precedence:

• explicit interface value, matching custom default, then factory default?
• It would also behelpful to add a test covering this inherited-default scenario.

For example, this should be valid because storm control is enabled through the access-interface defaults:

defaults:
vxlan:
  topology:
    switches:
      interfaces:
        topology_switch_access_interface:
          enable_storm_control: true

vxlan:
topology:
  switches:
    - name: leaf-1
      interfaces:
        - name: Ethernet1/1
          mode: access
          storm_control_broadcast_level_percent: 10

in this example, Rule 312 sees no enable_storm_control directly under Ethernet1/1, assumes false, and rejects the threshold even though the effective value inherited
from defaults is true.

live validation

Env: ND 4.1.1g / NDFC 12.4.1.321 · MCFG child fabric (FAB1) · targets NX-OSv (N9K-C9300v, 10.5(5))
Heads: validated live at 318b9cd; re-checked at 21d215e (delta = templates-only version gate, 0 rule changes)
Result: LGTM — features validated end-to-end; the "no config when not applicable" behaviors are by-design (see
Notes).

Negative / validation

Physical interface (subject Eth1/7, control Eth1/8 untouched)

Port-channels + copy_description

vPC / ToR pair